home *** CD-ROM | disk | FTP | other *** search
- Path: keats.ugrad.cs.ubc.ca!not-for-mail
- From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
- Newsgroups: comp.lang.c
- Subject: Re: Secure from Decompiling??
- Date: 14 Feb 1996 13:38:59 -0800
- Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
- Message-ID: <4ftkpjINNg7f@keats.ugrad.cs.ubc.ca>
- References: <4djaq2$jd5@earth.superlink.net> <31167bd7.15907136@netline-fddi.jpl.nasa.gov> <4fi9d4$g4l@redstone.interpath.net> <31211aae.2439037@netline-fddi.jpl.nasa.gov>
- NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
-
- In article <31211aae.2439037@netline-fddi.jpl.nasa.gov>,
- Kevin Quitt <kdq@emoryi.jpl.nasa.gov> wrote:
- >
- >>If a good
- >>decompiler can take an offset into memory and determine that a statically
- >>linked routine is a library function, it's pretty darn good.
- >
- >Why would it bother doing it the way you describe? Decompilers don't work on
- >the executable image, they work on the executable FILE. Certain things in
- >executables are clearly marked: for example, the entry point. By examining
- >the entry code and/or looking for copyright notices, it's possible to
- >determine the manufacturer of the compiler and usually determine the version
- >number. Simple binary comparisons based on knowing what the libraries are for
- >that version of that compiler trivially not only identify the library as such,
- >but also identify the names and types of parameters being passed to them, and
- >meaningful variable names can be generated. So by your definition, if not by
- >your method, this alone will make a decompiler "pretty good".
-
- What about string literals interspersed among code? I could randomly put
- fragments of what _seems_ like valid machine code into the literals.
- There are some _disassemblers_ that can't deal with embedded strings.
- I could, for instance, put inside a string literal what appears to be the start
- of a procedure, but is not well-formed. Without a symbol table, your decompiler
- would have to start at the entry point of the program, look for branches and
- divide the program into basic blocks by recursively following the control-flow
- hierarchy. This might succeed in isolating objects in the code section that are
- not code---or possibly code that is never called.
-
- Still, in C compiled programs, there is the possiblity that some functions are
- only called via dereference from function pointers (for example,
- statically-linked device drivers accessed from a structure table will typically
- never contain a direct branch to any of their code).
-
-
-
-
-
-
- >
- >>Okay, so where's the C++ decompiler that recognizes class libraries,
- >>then!?!
- >
- >Are there libraries that service these classes that are not used by anything
- >else? If so, they can be identified. Besides, you seem to have the idea that
- >a decompiler will produce a program identical to the original; it doesn't. It
- >merely produces a program that does the same things.
- >
- >
- >>How would a decompiler even KNOW that a class library
- >>was being used?!
- >
- >If you're interested, you can get their paper, or read my comments on the
- >page http://wwwis.cs.utwente.nl:8080/~faase/Ha/decompile.html. And if you
- >really are interested, instead of trying to prove it's impossible, start
- >thinking about what you could do to achieve. If you try to prove it's
- >impossible, it will be - for you.
- >--
- >#include <standard.disclaimer> http://emoryi.jpl.nasa.gov/
- > _
- >Kevin D Quitt USA 91351-4454 96.37% of all statistics are made up
-
-
- --
-
-